home *** CD-ROM | disk | FTP | other *** search
/ Night Owl 6 / Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso / 050a / asp_apl.zip / IMAGE.TXT < prev    next >
Text File  |  1991-05-01  |  15KB  |  355 lines
  1.  
  2.                           Building a Better Shareware Image
  3.  
  4.  
  5.           Introduction .................................................. 1
  6.  
  7.           The Problem and the Goal ...................................... 1
  8.  
  9.           How to Reach the Goal ......................................... 3
  10.  
  11.           Guidelines for Professionalism ................................ 4
  12.  
  13.           Specific Requirements ......................................... 5
  14.  
  15.           What the Requirements do not Cover ............................ 5
  16.  
  17.           Requirement Exceptions ........................................ 6
  18.  
  19.           Doing Your Part ............................................... 6
  20.  
  21.  
  22.  
  23.  
  24.           Introduction:
  25.           -------------
  26.  
  27.           The "image" of shareware is extremely important to the
  28.           Association of Shareware Professionals and to each of us as
  29.           shareware authors.  In order to build the best image of
  30.           shareware, especially of shareware produced by members of the
  31.           ASP, the following information and guidelines are presented.
  32.  
  33.  
  34.           The Problem and the Goal:
  35.           -------------------------
  36.  
  37.           Shareware.  What image does that word carry?  Unfortunately, far
  38.           too frequently it carries the image of poorly written software,
  39.           poor user interfaces, beg screens, annoying distractions geared
  40.           towards forcing you to register just to get rid of the annoyance,
  41.           mailing a registration payment and never hearing from the author,
  42.           weekend programmers greedy for your money, and many other bad
  43.           images.  In the eyes of many, the picture is not pretty.
  44.  
  45.           Remember Michael Covington's article in PC World (July '88)?
  46.           What could prompt an article like that?  Top quality software
  47.           with support that's among the best in the industry?  Authors
  48.           responding quickly and positively to the needs of their users?
  49.           Not a chance!  Any negative image is fostered and nurtured by
  50.           DemoWare, CrippleWare, NagWare, and worse.
  51.  
  52.           Every year more and more people are placing their programming
  53.           efforts into the shareware market to see what will happen.  In
  54.           the process they are making it harder for those of us to whom
  55.           shareware is a profession.
  56.  
  57.  
  58.           RRS Guidelines                                        Page 1 of 6
  59.  
  60.  
  61.                           Building a Better Shareware Image
  62.  
  63.  
  64.           Greed for squeezing every possible dollar from the public is
  65.           driving some authors to use practices which hurt the shareware
  66.           image and, in fact, fail to produce the intended results.  Some
  67.           shareware authors are literally spending more time and expending
  68.           more energy, devising ways to force the user to register, than
  69.           they are on developing the software itself!
  70.  
  71.           Some shareware authors sweat over ways to annoy and badger the
  72.           user into registering.  Others sweat over ways to make their
  73.           program the best it can be so users will WANT to register.  Some
  74.           shareware authors promote sales by scare tactics, misinformation,
  75.           and pure fabrication.  Others compete by providing better
  76.           support, better responsiveness, more power, more flexibility, and
  77.           a genuine concern for their users.
  78.  
  79.           Which will be spoken well of in the media?  In the user groups?
  80.           In the offices and homes?  Which will pass from hand to hand and
  81.           spread the fastest and the farthest?  But most importantly, which
  82.           approach will stand the test of time?  Which authors and programs
  83.           will be around years down the road?
  84.  
  85.           As professionals we must be concerned with the long term effects
  86.           of what we are doing today.  If shareware and the ASP are to
  87.           survive, then we must change the image of shareware.  We must
  88.           combat the bad images, the horror stories, and the tasteless
  89.           registration inducement tactics.  We must improve the image,
  90.           allay the fears, and promote professionalism.
  91.  
  92.           How are we going to do this?  We can talk until we're blue in the
  93.           face.  We can make official statements and public announcements.
  94.           We can mount a massive public relations campaign.  We can do all
  95.           this and more, and it won't make a bit of difference.
  96.  
  97.           There's only one way to improve the image of shareware, the ASP,
  98.           and ourselves - we must put our proof in our code.
  99.  
  100.           If we want people to have a positive image when they think about
  101.           ASP shareware, then we have to build that image with our
  102.           programs.  If we want to be viewed as professionals, then our
  103.           programs will have to look professional.  If we want users to
  104.           have confidence in ASP software, then ASP software must do
  105.           NOTHING to erode a user's confidence.
  106.  
  107.           If a program has to rely on harassing the user in order to
  108.           generate revenue then that program doesn't belong in the
  109.           shareware market.  The registration incentive should be the
  110.           quality of your program, not the user's desire to get rid of
  111.           annoying practices.
  112.  
  113.  
  114.  
  115.  
  116.  
  117.           RRS Guidelines                                        Page 2 of 6
  118.  
  119.  
  120.                           Building a Better Shareware Image
  121.  
  122.  
  123.           How to Reach the Goal:
  124.           ----------------------
  125.  
  126.           As shareware professionals we must promote professionalism,
  127.           quality, and respectability.  Users should think highly of our
  128.           programs, even if they don't register!  Satisfied users are more
  129.           likely to promote a product by word of mouth and by passing out
  130.           copies, than unsatisfied or annoyed users.
  131.  
  132.           Why do people register software?  They feel comfortable with it.
  133.           They have confidence in it.  It's easy to use.  It meets a need.
  134.           It's well written, powerful and flexible.  And more.
  135.  
  136.           What does NOT encourage users to register?  Forceful registration
  137.           screens.  Built in time delays.  Intrusions and interruptions in
  138.           the normal use of the program.  The need for missing functions
  139.           (DemoWare).  And more.
  140.  
  141.           Shareware programs have been successful with no registration
  142.           reminders at all!
  143.  
  144.           Aside from producing good quality, easy to use software, most
  145.           other registration encouragements have major weaknesses.
  146.  
  147.           * Execution counters and date based registration encouragements:
  148.           How do you know how long a program has been installed?  What if
  149.           the user doesn't use your installation program?  What if one user
  150.           installs a program, uses it for a few weeks, and copies the files
  151.           from his hard disk to a floppy for someone else?  The program is
  152.           already installed, so the other user uses it as is (the counters
  153.           are not reset).  That person might pass it on to others, upload
  154.           it to BBS's, etc.  At any given point in the chain it's very
  155.           difficult to tell how long a particular user has been using it.
  156.           It's very difficult to tell how many times a particular user has
  157.           executed the program.
  158.  
  159.           It is not uncommon for someone to acquire a shareware program,
  160.           use it a couple of times, and set it aside for months before they
  161.           get a chance to come back to it.
  162.  
  163.           * Time delays for registration reminder screens:  No user in
  164.           their right mind will read a registration screen every single
  165.           time they use a program during evaluation!  Why would you want to
  166.           force him to?  Faster and more powerful computers are being sold
  167.           everyday because people simply do not like to wait.  If you
  168.           deliberately force them to wait they will not appreciate it.
  169.  
  170.           * User interruptions and multiple key-press checkpoints:  These
  171.           tactics don't help users to feel comfortable with a program and
  172.           they don't help to build confidence in the software.  Do you want
  173.  
  174.  
  175.  
  176.           RRS Guidelines                                        Page 3 of 6
  177.  
  178.  
  179.                           Building a Better Shareware Image
  180.  
  181.  
  182.           the user to register because the program is worth registering, or
  183.           do you want to annoy the user into registering?
  184.  
  185.  
  186.           Guidelines for Professionalism:
  187.           -------------------------------
  188.  
  189.           By now you should have a pretty good overview of the problem, the
  190.           alternatives, and the effects those alternatives can have.  Here
  191.           are some guidelines that can help you to ensure that your
  192.           software will appear professional and courteous to those who use
  193.           it.
  194.  
  195.           Registration Reminder Screens:  A Registration Reminder Screen is
  196.           a reminder which requires user response, or which delays the
  197.           normal execution of the program while it is displayed.
  198.  
  199.           You do not have to use Registration Reminder Screens.  They are
  200.           strictly optional.  However, if you choose to employ such a
  201.           screen, there are a few details you should keep in mind.  These
  202.           screens should not attempt to intimidate or annoy the user into
  203.           registering.  Registration Reminder Screens are REMINDERS that
  204.           registration is required if they continue to use the program.
  205.  
  206.           Registration Reminder Screens should be employed with the user in
  207.           mind.  Perhaps you want to display a Registration Reminder Screen
  208.           when the program starts, or when it ends, or both.  Perhaps you
  209.           want to leave the text on the screen when the user returns to
  210.           DOS.  If your program is a TSR, you might want to display the
  211.           screen the first time the user pops-up your program.
  212.  
  213.           You should avoid minimum delay periods where the Registration
  214.           Reminder Screen takes control of the computer and forces the user
  215.           to wait.  In any event, a minimum delay period must not exceed 3
  216.           seconds.
  217.  
  218.           The "Press any key to continue" approach is preferred over the
  219.           delay period approach - it leaves the user in control, which they
  220.           will definitely appreciate.  However, when taken to the extreme,
  221.           the keystroke-to-continue approach can get annoying too.  You
  222.           don't want to interrupt the user over and over again to "Press
  223.           any key to continue".  You also don't want to require the user to
  224.           enter some random number or string to get past a particular
  225.           point.  It should never take more than two keystrokes to get past
  226.           a Registration Reminder Screen.
  227.  
  228.           There are many ways a Registration Reminder Screen can be used
  229.           without interfering with the use and evaluation of your program.
  230.  
  231.  
  232.  
  233.  
  234.  
  235.           RRS Guidelines                                        Page 4 of 6
  236.  
  237.  
  238.                           Building a Better Shareware Image
  239.  
  240.  
  241.           ------------------------
  242.           Specific ASP Guidelines:
  243.           ------------------------
  244.  
  245.           Registration Reminder Screens should:
  246.  
  247.                1) be displayed no more than twice each time the program
  248.                runs (or twice per day for long-running programs such as
  249.                TSR's).
  250.  
  251.                2) not require more than two keystrokes to bypass.
  252.  
  253.                3) not have a forced minimum display time of more than three
  254.                seconds.  In other words, the RRS itself should not take
  255.                control of the computer away from the user for more than
  256.                three seconds.
  257.  
  258.           Practices such as creating undocumented hidden files or printing
  259.           a registration form without the user's knowledge or consent are
  260.           prohibited.
  261.  
  262.  
  263.           What the Guidelines Do NOT Cover:
  264.           ---------------------------------
  265.  
  266.                1) Registration reminders may be displayed anytime the user
  267.                specifically requests registration information.
  268.  
  269.                2) Simple messages such as a status line stating
  270.                "Unregistered" or "Evaluation Version" are acceptable as
  271.                long as they require no interaction from the user and do not
  272.                hinder the normal functioning of the program.
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.           RRS Guidelines                                        Page 5 of 6
  295.  
  296.  
  297.                           Building a Better Shareware Image
  298.  
  299.  
  300.           Guideline Exceptions:
  301.           ---------------------
  302.  
  303.           If your program falls within these guidelines then you will be
  304.           helping to improve the image of shareware.  You will be part of
  305.           the solution rather than part of the problem.
  306.  
  307.           It is absolutely essential that the ASP protects its image and
  308.           reputation.  Because of this, if you feel that you need to
  309.           stretch the limits of these guidelines, or go outside of the
  310.           guidelines entirely, then you will need approval from the Board
  311.           of Directors, or from a committee set up by the Board for the
  312.           purpose of handling these issues.
  313.  
  314.           The ASP has no desire to control your life or your business, but
  315.           the ASP has a responsibility and duty to its members and users.
  316.           The image and future of shareware demands that the responsibility
  317.           be taken seriously.
  318.  
  319.  
  320.           Doing Your Part:
  321.           ----------------
  322.  
  323.           Think carefully about the implementation and appearance of any
  324.           registration reminders you intend to employ.  Get feedback from
  325.           other members, from your beta testers, and from your users.  Find
  326.           out how others feel about your approach.
  327.  
  328.           Let's send a message to the computer industry.  A message that
  329.           says shareware authors are serious.  Shareware authors are
  330.           talented, capable, and professional.  Let's send that message
  331.           through the programs we market.  Thanks for helping to make
  332.           shareware the best it can be!
  333.  
  334.  
  335.  
  336.           These requirements were voted into effect on January 12, 1991
  337.           during the ASP's Annual Meeting on CompuServe.  All programs
  338.           produced by ASP Author Members must conform to these
  339.           requirements.
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.           RRS Guidelines                                        Page 6 of 6
  354.  
  355.